Date: Thu, 18 Feb 93 04:30:13 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #46 To: tcp-group-digest TCP-Group Digest Thu, 18 Feb 93 Volume 93 : Issue 46 Today's Topics: 16550 uart chip source in BC. ARRL Petition to "kill" AX.25 -- some factoids Book on NOS! Death of AX.25 looooooooooooooooooooooooooooooooooooong messages New ax25? (7 msgs) New files at UCSD.EDU PNEWS & BM 3.3.2b new firmware? (2 msgs) nos bug query NOSintro - TCP/IP over Packet Radio subscribe Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 17 Feb 93 11:17:21 pst From: JAMES_DEAN Subject: 16550 uart chip source in BC. To: tcp-group@ucsd.edu, nos-bbs@hydra.carleton.ca The SysAdmin at the QUESTOR Project, Steve Pershing in Vancouver is offering the National CP16550AFN chip for $16 CDN, each. Send him an e-mail to order. I saw his offer posted in the 'comp.dcom.modems' news list dated 13 Feb 1993, and have ordered two for myself. [His offer there was for $12 US/plus shipping]. Phone numbers given in his message are: (+ 604) Voice: 682-6659, Data: 681-0670 and Fax: 682-6160 As a side note, are there any complications in simply replacing the 16450 with a 16550? The manual I have says they are pin-for-pin except for two pins, one of them NC on the 16450. Does a standard PC application of the chip care about that difference? Cheers, James. -- James Dean National Research Council Canada Dominion Radio Astrophysical Observatory Penticton, BC [604]493-2277 ------------------------------ Date: Thu, 18 Feb 93 05:56:23 UTC From: clark@tomcat.gsfc.nasa.gov (Tom Clark -- W3IWI) Subject: ARRL Petition to "kill" AX.25 -- some factoids To: tcp-group@ucsd.edu There have been some tcp-group comments that I interpret as flamage and/or misinformation concerning the ARRL petition to the FCC that drops the AX.25 requirement. Let me try to set the record straight by giving a brief review (seen with my personal myopic biases) of the background. For those of you who want to read the complete text of the ARRL's proposal, it is available by anonymous ftp from tomcat.gsfc.nasa.gov in ~/public/fcc/arrl_hf.txt (42706 bytes long). Thanks to Dave Speltz, KB1BD for making the material available. Note that this proposal only discusses the HF bands, 30 MHz and down. As the "new boy on the block" packet has had a hard time shoe-horning itself into a very congested spectrum with a new technique. The present automatic HF packet activity using AX.25 is carried out under the aegis of an FCC Special Temporary Authorization (STA) that dates back far too many years. The bulk of the existing rules date back to 1934 and clearly new techniques needed to be accommodated. The ARRL had made two previous abortive attempts to replace the STA with some suitable new rules that would allow for automatic digital operation on HF. The first attempt to write some rules that would permit automatic operation ran afoul of the RTTY/AMTOR folks and the International powers that be (specifically IARU, more specifically Region 2, and even more specifically from Central and South American countries). That proposal was withdrawn "without prejudice". Those who worked hard on that proposal (W4RI, AD7I, WA7GXD and others) felt pretty bloodied by the experience. In late 1991 & early 1992, the ARRL appointed a new Digital Committee (DC), charged them with solving the problem and published a questionnaire in QST and RTTY Journal. The Packeteers didn't get the word and were not very responsive. The DC took what responses it got (mostly from the RTTY and AMTOR users) and wrote a proposal which was published early last summer. The Packet community rose up in arms, said this isn't going to work, and made life generally unpleasant for both the DC and the ARRL BoD. The ARRL BoD in August decided that some of those active in the current packet STA needed to meet with the DC to try to find a compromise. The STA community elected the "Gang of Five" (GOF) consisting of W0RLI, KD7XG, WA0CQG, AD8I and W3IWI to met with the DC in late September to solve the problem. Through August and September the Packet community formed and active working group (hfnet@amsat.org) which tried to sort out the our view of the alternative universe. Then, Lo and behold at the IARU Region 2 meeting in Curacao in early September, the politicos decided that Packet did have a place on HF and the managed to develop a workable band plan. One thing that had changed was that the Latinos now realized how useful HF packet networks were in developing countries and they WANTED space for them. Given the new IARU position, the DC and the GOF unanimously negotiated a compromise that seemed acceptable to all factions and which adhered to the IARU band plan, and recommended this as the position the ARRL should take vis-a-vis digital communications on HF. It recognized that all the "modes" were serving a useful purpose, and it said that they were all evolving. Digital communications a few years hence probably would not look like ANYTHING now on the air. We would see adaptive DSP modems, convolutional encoding to improve error rates, block-oriented "hole-filling" protocols (a la the PACSATs), etcetera etcetera. Nobody wanted to see us stuck with obsolete protocols be they ordained by the CCITT (like TOR) or VHF packet practice (like AX.25). I was the one who suggested that it should be adequate to have the protocols in use be published (without saying where). My idea was that we could essentially follow an RFC-like schema, with protocols published for comment and available openly for anyone who really wanted to figure out what the bits meant. When the ARRL Board finally acted on the DC report, the fine-tuned the frequency segments (mainly to avoid tromping on the 40 & 15M novices so much) but I was VERY relieved to see that they let stand the "published protocol" wording. At the DC/GOF meeting, the main dissension concerned "semi-automatic" op- eration (which is what the AMTOR and RTTY MSO people claim the have been doing legally for many years), wherein at least one end of a path has a human operator. The GOF felt that this was a subterfuge, operation is either automatic or it ain't (you can't be semi-pregnant!). In the report we agreed to disagree. The ARRL BoD dropped all references to "semi-automatic" operation, and the proposal only uses the words automatic and unattended. The petition has been filed with the FCC. To my knowledge it has not been assigned an RM number and the comment period has not been opened. But when it is opened, I urge that the advanced networking community (represented by the people in this august group) should support it wholeheartedly. If the FCC accepts the premise that amateurs can develop new, cost-effective, efficient technologies on the HF bands where the "wire is incredibly poor", then we have strong grounds to offer a similar solution to make a "better AX.25" (or A-802.x or whatever). FYI, when the ARRL submitted the petition to the FCC, they had the current HF STA extended until the RM procedure ran its course. ------------------------------ Date: Wed, 17 Feb 93 06:31:38 MST From: rnielsen@tapr.ampr.org (Bob Nielsen) Subject: Book on NOS! To: tcp-group@ucsd.edu John Ackermann AG9V writes: > You (Russell Nelson) write: > > > > Yeah! Finally! Ian Wade, g3nrw, wrote a book on NOS. I don't know > > enough about amateur radio to say if it adequately describes the > > AX.25, PBBS, and NET/ROM stuff. I can say for sure that it explains > > things I never understood before. > > I got a complimentary copy from Ian on Monday. I haven't had a chance > to do more than dip into it yet, but it appears to be well > done... a serious cut above the usual Tab Books crap that most ham books > seem to be these days. > > I think I'll probably be recommending it to people who want something > more substantial than the currently available docs (mine included...). > Though he may not cover a lot of territory that the existing docs don't, > with the luxury of 300 pages to work with he can do a lot better job of > explaining things. > > John AG9V > I noticed a new version of Ian's nosview at ucsd.edu in the /incoming directory (I forget the exact path). Bob Nielsen W6SWE ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org amateur IP: 44.124.12.16 CIS: 71540,2364 ------------------------------ Date: Wed, 17 Feb 1993 10:50:36 -0500 From: goldstein@carafe.tay2.dec.com (k1io, FN42jk) Subject: Death of AX.25 To: tcp-group@UCSD.EDU IS THIS THE ARRL UP TO ITS TRICKS AGAIN? Sheesh! Requiring a Morris Code (that's the county; Vail invented the code) test in order to route packet? That's insane, but totally in keeping with the ARRL traditions. But that's not all. What really gets me is the term "accepted protocol". No lawyer would ever let that get into the CFR unless they were acheing for a battle. Accepted by Wayne Green? Accepted by Fred Goldstein? Accepted by the ghost of Harry "Morse Forever" Dannals? Accepted by the FCC? In the latter case, the acceptance would take the form of an enumeration in the regs., which right now means "AX.25", the ARRL abomination. One of two rules should apply: 1) Identify every 10 minutes while in operation, and use any mode. 2) Identify the call sign in every packet. This breaks down into two obvious mechamisms. 2a) Include "plain ASCII" in the protocol header. Easy enough iff you grow a protocol from scratch. 2b) Use the same mechanism of Ident as AX.25, which is left-shifted ASCII in the header. Odd but all that we're now allowed. I'd be happy enough with Rule 2; that would let us move beyond AX.25. But I'd also like to allow rule 2c as an option: 2c) If using forward-error correction, identify in FEC-encoded ASCII, using a published FEC algorithm identified in the station log, and, if necessary, per rule 1) above. I don't t hink the FCC wants to be overly restrictive, but if the League demands it, they tend to go along. fred k1io ------------------------------ Date: Thu, 18 Feb 93 12:54:43 PST From: "Jerzy Tarasiuk" Subject: looooooooooooooooooooooooooooooooooooong messages To: DECARLIS@MTUS5.cts.mtu.edu, tcp-group@ucsd.edu when you really need to send something long, *PLEASE* pkzip and uuencode it. And put some text info what it is. Your msg exceeded 100kB and some mailers may have a little trouble handling it. Pkzip+uuencode would produce file 2 times shorter (50kB only)! 73's, JT ------------------------------ Date: Wed, 17 Feb 93 14:18:56 GMT From: Michael Chace Subject: New ax25? To: Phil Karn (Phil Karn) >>>>> Regarding Re: New ax25?; Phil Karn (Phil Karn) adds: >Ok, well start by replacing the CSMA Medium Access Control. How about some >form of Token Ring? Phil> There are, in my opinion, much better access protocols for radio Phil> channels than token ring. Token ring is complex, introduce long Phil> delays when the channel is nearly idle, and don't work well when Phil> loss rates are high (token recovery is the most complex and time Phil> consuming part of these protocols.) Phil> There are many things you can do to CSMA to make it work much Phil> better, you don't have to throw it out entirely. Not only that, but there are other practical and *implemented* systems to improve things - the DAMA extensions to AX.25 spring to mind. As far as I can ascertain, DAMA is catching on in some parts and does seem to make a noticeable difference. Perhaps some of the German list readers can comment further ? Mike **** ------------------------------ Date: Wed, 10 Feb 93 21:11:33 -0800 From: Phil Karn (Phil Karn) Subject: New ax25? To: tcp-group@ucsd.edu |> Yes, I think most of us agree AX25 needs replacing, lets experiment! with |> something new. |> I guess we have to define our problem a bit more and then we can start |>working |> on it. Well, I wasn't talking about replacing AX25, I was talking about creating a new network layer to sit between it and IP. But since you bring it up, yes, we could certainly use a new link layer protocol. |Ok, well start by replacing the CSMA Medium Access Control. How about |some form of Token Ring? There are, in my opinion, much better access protocols for radio channels than token ring. Token ring is complex, introduce long delays when the channel is nearly idle, and don't work well when loss rates are high (token recovery is the most complex and time consuming part of these protocols.) There are many things you can do to CSMA to make it work much better, you don't have to throw it out entirely. Phil ------------------------------ Date: Thu, 18 Feb 1993 09:52:05 +1000 From: makinc@hhcs.gov.au Subject: New ax25? To: tcp-group@ucsd.edu Lyndon writes; > by backwards regulations?) Actually the whole concept of the SSID > should be scrapped - it doesn't belong this far down the stack. We need some method to differentiate different stations operating under the one callsign. I have up to 5 going at once, some on the same channel. Using the callsign is fine but we also need SOME way to distinguish further stations under that callsign. Carl. -- Carl Makin (VK1KCM) Systems Programmer Internet: makinc@hhcs.gov.au Amprnet: vk1kcm@vk1kcm.act.aus.oc Work Phone: +61 6 289-9443 ------------------------------ Date: Thu, 18 Feb 93 09:55:01 EST From: dave@eram.esi.com.au (Dave Horsfall) Subject: New ax25? To: tcp-group@ucsd.edu [ Warren VK1XWT ] > I would like to see callsigns kept as unique identifiers a la Ethernet > addresses at the data link layer. But I agree, routing via callsigns > is an abomination. But for heaven's sake, let's not restrict it to an arbitrary 6 bytes! This is what kept special event callsigns VI88NSW, VI150SYD etc from being used on packet radio... -- Dave ------------------------------ Date: Wed, 17 Feb 1993 15:24:50 -0800 From: Lyndon Nerenberg Subject: New ax25? To: makinc@hhcs.gov.au, tcp-group@ucsd.edu Well, the callsign doesn't belong in every packet, either - it's extra overhead that just isn't needed. If you need to identify your transmitter to comply with regulations, send an ID packet whenever its require. This business to tying the callsign to the MAC address was a mistake. ------------------------------ Date: Thu, 18 Feb 1993 13:22:49 +1000 From: makinc@hhcs.gov.au Subject: New ax25? To: tcp-group@ucsd.edu Lyndon Nerenberg writes; > Well, the callsign doesn't belong in every packet, either - it's extra > overhead that just isn't needed. If you need to identify your transmitter > to comply with regulations, send an ID packet whenever its require. This > business to tying the callsign to the MAC address was a mistake. So how else are you going to generate a unique and reproduceable address for that layer? Using the callsign of the station with some other identifying information makes it reasonably easy to keep the identification unique. BTW I'm not in the US and, at the moment, simply ID'ing every 9 minutes isn't enough to keep it legal here. :-( (Changes should be here soon though that will make that legal) Digressing a fair bit, Phil mentions he would like to see some sort of "LAN" routing scheme setup below IP to give IP the fully connected network it wants. This seems a "good" idea to me as it would allow *much* easier inter-operability between established (and dominating) IP networks and the Amateur Service. Instead of trying to patch IP we give it the sort of connectivity it assumes is present and design a protocol specifically to handle the problems a Radio network (such as we have) presents. I suppose it would look something like this; .. .. +-------------- | IP +-------------- | "LAN" connectivity protocol +-------------- | Link protocol +-------------- It would present to IP a model of the network pretty much as if was a *very* slow ethernet. It would need to support the following; Broadcasts, Multicasts, Point to point unreliable, unconnected delivery. Full and half duplex links, One way and multiple paths, Anything else? Comments? Carl. vk1kcm. -- Carl Makin (VK1KCM) Systems Programmer Internet: makinc@hhcs.gov.au Amprnet: vk1kcm@vk1kcm.act.aus.oc Work Phone: +61 6 289-9443 ------------------------------ Date: Wed, 17 Feb 1993 22:22:39 -0800 From: Lyndon Nerenberg Subject: New ax25? To: makinc@hhcs.gov.au, tcp-group@ucsd.edu > So how else are you going to generate a unique and reproduceable address > for that layer? Using the callsign of the station with some other > identifying information makes it reasonably easy to keep the identification > unique. Well, the address only has to be unique within the subset of stations that can hear each other. I would use a 16 bit station address. When a station comes on the air it picks a random value and broadcasts it out the appropriate port. If the address is already in use the existing address holder sends out a "sorry, try another one" reply, and the process repeats until a unique address is found. (Now where have I seen *that* before :-) --lyndon ------------------------------ Date: Wed, 17 Feb 1993 20:03:30 +0200 From: Costas Krallis SV1XV Subject: New files at UCSD.EDU PNEWS & BM 3.3.2b To: tcp-group@ucsd.edu The new release of PNEWS (Pnews 1.05 ) is to be uploaded to ucsd.edu in the incoming directory tonight. The new release of BM v. 3.3.2b is to be uploaded to ucsd.edu in the incoming directory tonite. 73 Costas SV1XV ------------------------------------------------------------------ | Dr. K. Krallis SV1XV * Epsilon Software S.A. | ------ | Internet: kkrallis@leon.nrcps.ariadne-t.gr | Packet radio: SV1XV @ SV1IW.ATH.GRC.EU | AMPRnet: sv1xv@sv1xv.ampr.org [44.154.1.11] | Snail Mail: P.O.BOX 3066, GR-10210 Athens, GREECE ------------------------------------------------------------------ ------------------------------ Date: Wed, 10 Feb 93 21:11:11 -0800 From: Phil Karn (Phil Karn) Subject: new firmware? To: tcp-group@ucsd.edu At 10:37 2/9/93 -0800, Jeffrey D. Angus wrote: |KISS Mode? The only things that would have to stay constant while re-using |existing TNCs are the BELL-202 modem and the 8530 HDLC. Actually, if you really want to redo amateur packet radio right from the ground up, even these have to go. I'm becoming convinced that some form of forward error correction (FEC) is essential, at least as an option when links get bad, and this pretty much precludes HDLC framing. I've been working on a sequential (Fano) decoder to a convolutional code that runs fast enough on a 486 to handle a 56kb/s modem without any trouble given channel bit error rates as high as several percent. This would deal nicely with the 70cm radar problem we have in southern California, among other things. The reason FEC precludes HDLC framing is because you need a much more robust synchronizing sequence to start off each frame. An HDLC flag is much too short. You need something more like 32 or 64 bits long that can be recognized reliably by a correlator even when a substantial fraction (say 10%) of the bits are in error. The Bell-202 modem I won't even talk about. Phil ------------------------------ Date: Wed, 17 Feb 93 11:38:41 CST From: andyw@aspen.cray.com (Andy Warner) Subject: new firmware? To: tcp-group@ucsd.edu (TCP Group) Phil Karn wrote :- > [...] > The reason FEC precludes HDLC framing is because you need a much more > robust synchronizing sequence to start off each frame. An HDLC flag is > much too short. You need something more like 32 or 64 bits long that > can be recognized reliably by a correlator even when a substantial > fraction (say 10%) of the bits are in error. Some folks up here in the tundra of MN have been looking at a chip that does Reed/Solomon (probably passe technology by now) and serialisation, and scrambling. It's a production chip, it's just not built for radio links. One lesson that it took me a while to learn was that the current way we use radio means that we can ignore things like ensuring 1's density, and stability of the symbol rate, since there are no long-term effects (ie, a 1% change in rate during a 2 second transmission is OK, but if it were a full time link, that kind of drift would be clearly unacceptable.) Exploiting this fact might let us simplify the tx, and allow the RX to track. Of course, who's to say that the rx then doesn't become overly complex.... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Wed, 10 Feb 93 21:12:36 -0800 From: Phil Karn (Phil Karn) Subject: nos bug query To: tcp-group@ucsd.edu For those of you having problems with file opens, you may need to increase the number of MS-DOS FILE handles you allocate in your config.sys file. Recent versions of NOS use file handles prodigously, especially now that each session has a scrollback buffer (which is kept in a temporary file). One of my reasons for rewriting my own stdio was to get around the limit of 20 open files that's hard-coded into the Borland library. (Yes, you can modify their source and recompile, but I had other reasons too.) But to take advantage of this, you also need to allocate enough file slots in MS-DOS itself. And that's what the FILES= command in config.sys does. Phil ------------------------------ Date: Wed, 17 Feb 1993 13:00:37 -0500 From: goldstein@carafe.tay2.dec.com (k1io, FN42jk) Subject: NOSintro - TCP/IP over Packet Radio To: tcp-group@ucsd.edu Sounds like a good book. Question: Is the book mainly written for end users, as in "here's how to use NOS", or does it provide a technical discussion of the code itself, as in "these are the modules, here's how it works, etc."? fred k1io ------------------------------ Date: Wed, 17 Feb 93 16:31:26 GMT From: pizzico@ntt.glt.esercito.it (Pasquale Pizzichetti) Subject: subscribe To: tcp-group@ucsd.edu subscribe ----- Pasquale Pizzichetti (IK3NGU) 10 ------------------------------ Date: (null) From: (null) In terms of making inputs to the ARRL, be advised that Ed Juge, W5TOO has resigned from the DC because of business pressures. I'm not sure who the members are today. I'd suggest contacting the ARRL BoD liaison (Tom Comstock, N5TC) or the HQ liaison (Jon Bloom, KE3Z). None of the GOF that helped the DC come up with this solution has any advisory role -- our duties ended when we got back on the airplane that fateful Sunday in Dallas. In addition to the DC, the ARRL has a "distant vision" committee (I know KA9Q and WA7GXD are on it, but I've never seen a full list of members). One or both of these ARRL committees would seem to be the place to start planting the idea that we need more flexibility in developing future communications protocols. And FYI, the small working group that was formed a few months ago still "meets" as hfnet@amsat.org for anyone who wants to participate. Send a request to listserv@amsat.org if you feel a compelling desire to join. 73 de Tom, W3IWI clark@tomcat.gsfc.nasa.gov ------------------------------ End of TCP-Group Digest V93 #46 ****************************** ******************************